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(S7) Abstract: A sysiem and methcxl fur performing modeling, prediction, opiimization. and control, including an enierprise wide 
framework for constructing modeling, optimization, and control solutions, llie framework includes a plurality of base classes that 
may be used to create primitive soflware objeas. These objects may then be combined to create optimization and^or control solutions. 
'Vhe distributed event-driven component architecture allows much greater flexibility and power in creating, deptoying. and modifying 
modeling, optimizadon and control solutions. The system also includes various techniques for performing improved modeling, 
optimization, and control, as well as improved scheduling and control. For example, the sysiem may include a combination of 
batch and continuous processing frameworks, and a unified hybrid modeling framework which allows encapsulation and composition 
of different model types, such as first principles models and empirical models. The system may further include a more 'flexible 
con6gar2tion of the decision -making hierarchy. The system further includes an integrated process scheduling solution referred to as 
process coordinator, which is an enterprise scheduling / control application that seamlessly incorporates the capabilities of advariced 
control and execution into a real dme event triggered optimal scheduling soludoa The process coordinator includes a number of 
innovations, including schedules based on real lime informalion, uniHcation of scheduling and control tasks, and blending of batch 
and continuous representations, l^e process coordinator system may thus operate to combine scheduling and control into a powerful 
hybrid environmenL 
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TEIU;: SYSTEM AND METHOD FOR ENTEBPRISE MODELING, OFTIMIZAIION AND CONTROL 



Background of the Invention 

5 

Field of the Invention 

The present invention generally relates to the fields of modeling, optimization, and control More 
paiticulariy, the present Invention relates to providing an enterprise wide framewoik for constructing modeling, 
bptimization, and control solutions. The present invention further relates to various techniques for perfonning 
10 improved modeling, optinuzation, and control, as vcU as inqnoved scheduling and TO 

Description of the Related Art 

Numerous industries are in the midst of a technological revolution. Throughout today's businesses, 
information is being made available &om diverse sources at a rapid rate. In addition, abundant amounts of historical 

15 data from these sources are accumulating but are not being iiilly leveraged. Customers expect immediate responses 
and demand the highest quality products and services. To remain conq)etitive, businesses must be able to operate 
optimally while fulfilling the customers' needs. 

The need to operate optimally requires that busmesses be much more flexible, have immediate access to 
different forms of informatipn ihroi^out i|ie enterprise, and be able to use this infonaation to solve problems in 

20 real time. A business must be able to utilize the information effectively and react to the information as it becomes 
available rather than waiting for it to appear in periodic reports. The problem is that the information comes from 
different areas of the business, has different meaning to different levels of the business operation, and is utilized in 
different ways. The business nnist be able to gadier information, analyze the information, utilize die infonnation, 
and execute decisions all in an optimal manner widi respect to the entire business in order for it to operate most 

25 profitably. 

Tools have been developed to improve separate aspects of business operations. Examples include tools for 
simply chain management and advanced process controL However, these tools applied in isolation do not solve the 
enterprise-wide problems. An enteiprise-wide solution is one that views the business as a whole. Although 
businesses have tried to integrate different individual solutions to achieve an enterprise-wide solution, these 
30 attempts have foiled. 

Integration of separate solutions into a single business solution is often misrepresented. The benefit of 
integration comes not from loose bridging between disjoint applications but rather 'from designing, from the 
beginning, tight integration of different applications. For example, one decision process cannot produce an optimal 
decision without knowing both the state of the process dxat it affects and die ramifications of diat decision on the 
35 dependent processes. 

Any successful solution to the enteiprise-wide problem should have an integrated architecture that 
combines many diverse technologies into a unified framework. An enterprise-wide sohition should have extensive 
information4iandling capabilities, a complete set of automatic decision-making tools, and a flexibfe architecture 
that addresses the broad scopo of problems feced throughout die enterprise. 
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Figure 1 iUustiates the concept of automated decision making accoiding to the piior art In automated 
decision making, it Is presumed that a process or system exists upon which decisions are to be made. Part of ttie 
automated decision making process is to collect data, e.g.» tustorical data of ^t process, and use this information to 
build knowledge or information about how the process behaves. This leaxidng or knowledge may be continually 
5 added to or refined as the process is controlled. The information or knowledge ttat is gathered over time can then 
be used to perform intelligent decision makiDg. For example, the knowledge about how the process behaves can be 
combined with goals and objectives of how ttie process is desired to behave in order to generate actions that can be 
used to manipulate the behavior of the process or system. Thus, a model of the system or process can be used in 
addition to a solver or optimizer that optimizes the process according to a desired problem formulation or objective 
10 function. 

Figure 2 is a flowchart, diagram generally illustrating the prior art method of creating and using models and 
optimization procedures to model and/or control a process. As shown, in step -202 the method involves gathering 
historical data which describes die process. This historical data may comprise a combination of inputs and the 
resulting outputs when diese inputs are affiled to die respective process. This historical data may be gathered in 

1 S many and various ways. TypicaOy, large amounts of historical data are available for most processes or enteiprises.- 
In step 204 the metiiod may preprocess the historical data. The preprocessing may occur for several 
reasons. For example, preprocessing may be performed to manipulate or remove error conditions or missing data, 
or accommodate data points tiiat are marked as bad or erroneous. Preprocessing may also be performed to'filter out 
noise and unwanted data. Further, preprocessing of the data may be performed because in some cases the actual 

20 variables in die data are themselves awkward in modeling. For example, where the variables are temperature I and 
tenqierature 2, the physical model may be much more related to tfie ratio between the tenq;)eiatures. Thus, rather 
than apply temperature 1 and tenqperature 2 to the model, the data may be processed to -create a syndetic variable 
which is die ratio of tiie two ten^rature values, and the model may be used against die ratio. 

In step 206 the model may be created and/or trained. This step may involve several steps. First, a 

25 representation of the model may be chosen, e.g., choosing a linear model or nonlinear model If die model is a 
nonlinear model, the model may be a neural net structure. Further, the neural net structure may be a %lly 
connected neural net or a partly connected neural net. After the model has been selected, a training ^gorithm may 
be ^plied to the model using die historical data, e.g., to train the neural net Finally, the method may verify the 
success of this training to determine whether flie model actually correqionds to the process being modeled 

30 In step 212 the model is typically analyzed. This may involve applying various tools to the model to 

discover its behavior. 

Finally, in step 214, the model may be d^loyed in die '^al world" to model, predict, optimize, or control 
die respective process. The model may he deployed in any of various maimers. For example, die model may be 
deployed singly to perform predictions, which involves specifying various iiiputs and using die model to predict 
3S the ou^ts. Alternatively, the model may be employed with a problem formulation, e.g., an objective function, and 
a solver or optimizer. 

Figure 3 iUustrates the traditional prior art appioach to scheduling/optimization problerns. F^;ure 3 is a 
gn^h which ilhistrates various types of decisions and the prior art methods typically used in making tiicse 
decisions. The graph has two axes as shown. The X axis rq;>resents the process and decision type. The X axis 
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represents the process type ranging from coatinuous processes at tihe origin, to batch' processes, and then to discrete 
processes. In a continuous process, material is continuously flowing through a system, and the automation sohstion 
may be Continuously gathering measurements and continuously making decisions. A batch process presumes that 
the process occurs in batches. The Y axis represents the scope and resohitioo of the decisions being made. At the 
S origin, ihc scope and resolution of the decisions are local involving very simple decisions. As Y increases decisions 
become more con^lex, until at the highest point of the Y axis die system involves planning the strategy of a whole 
enteipxise. 

As shown in Figure 3, prior art solutions applied in this matrix are typically very distinct in nature. For 
example, control solutions in a continuous worid and a control solution in a batch world have very littb commcxi 
10 software or common representation. Rather, these are typically different products. This limits tf» ability to create 
more interesting and intelligent solutions to various problems. 

As shown, the prior art approach has typically used an "islands of technology^ approach coxrq>rising 
separate applications, e.g., a separate scheduler application, a separate recipe execution application, and a separate 
controller application. A solution provider may then attempt to combine ttiese separate af^lications using a foma of 
IS '^ghie logic'* that enables some forms of primitive communication. One of die drawbacks widi dus traditional 
approach is diat die applications generally can only exchange basic^ static information. La addition, these different 
higb-level applications typically have differences in modeling, framework, communication, visualization, and 
execution, and lack adequate intercommunication to provide a true enterprise- wide solution. 

Thus, the traditional prior art approach to decision making across the enterprise may be referred to as 
20 "system integration". The prior art method presumes different pieces of softwaro that may perform different 
functions, such as continuous control, batch control, optinnzation, sdieduling, etc., and these different pieces aro 
"glued together" to attettqpt to provide an enterprise solution. In addition* as mentioned above, each of these 
different twiications cannot take advantage of all of the enteiprise data which would be desirable to optimize die 
entire enterprise. 

•25 Therefore, an in^roved system and mediod are desired for providing a modeling, optimization, and 

. control system. An improved system and method arc also desired for providing various improved modeling, 
optimization, and control techniques. 

Summary of the Invention 

30 The present invention oonoprises various embodiments of a system and method for performing modeling, 

prediction, optimizatioii, and controL In one embodiment, the present invention includes an enterprise wide 
j&amework for constructing modelings optimization, and control solutions. The framework includes a distributed 
event-driven component architecture which allows much greater flexibility and power in creating, deploying, axsd 
modifying modeling, optimization and control solutions. 

35 hi another enibodiment, the present invention includes various technicpies for performing improved 

modeling, optimization, and control, as well as improved schedoling and controL For example, the system may 
include a conibination of batch and continuous processing frameworks, and a unified hybrid modeling framework 
which allows encq;)Sulation and conqposition of different model types, such as iEirst principles modete and empirical 
modek. The system may furdier include a mxao flexible configuration of the decision-making hierarchy. 
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Another embodiment of the invention inchides an integiated process scheduling sohilion referred to as 
'"process coordinator''. In one embodiment, the process coordinator is designed as an enteiprise scheduling / 
control application that seamlessly incorporates the capabilities of advanced control and execution into a real tune 
event triggered optimal scheduling solution. The process coordinator of diis embodiment includes a number of 
S hwovattom, including schedules based on real time xnfomuition, unification of sc heduling and oontiol tasks, and 
blending of batch and continuous representations. The process coordinator system may ttuis operate to combine 
scheduling and control into a powerful hybrid environment This operates to provide a more enterprise-wide view 
of die con^lete solution or system^ enabling more intelligent scheduling and conlroL 

10 Brief Pescription of the Drawings 

A better understanding of tiie present invention can be obtained when the following detailed description of 
the prefened embodiment is considered in conjunction with the following drawings, in which: 

Figure 1 illustrates ^e concept of automated decision makmg according to die prior ait; 
Figure 2 is a flowchart diagram generally illustrating (he prior art method of creating and using models and 
IS optimization procedures to model and/or control a process; 

Figure 3 ilhistzates the traditional prior art approach to scheduling/optimization problems; 
Figure 4 illustrates a simplified and exeiiq;>l8iy view of one embodiment of a system according to the 
present invention; 

Figure 5 illustrates the component architecture according to one embodiment of die invention; 
20 Figure 6 illustrates representative exaxnples of various of die component or object classes comprised in the . 

aichitecture of the preferred embodiment; 

Figure 7 illustrates an exanqile of an encapsulatsd decision engine; 

Figure 8 illustrates the Decision Engine comqponent used as a modular component or object in a hi£^r 
level solution; 

25 Figure 9 illustrates the graph of Figure 3, but having the approach used according to one embodiment of 

the invention; 

Figure 10 illustrates die interactions of events between enterprises; 
Figure 11 iUustrates the unified modeling firamewoik according to one embodinien^ 
Figure 12 illustrates an example of model aggregation according tt> one embodiment of die invention; 
30 Figure 13 iUustrates two exaniplesoftraditionaldecision-rnaking hierarchies; 

Figure 14 illustrates a flexible decision-makii^ hierarchy according to one embodiment of die inventioi^ 
Figure 15 illustrates a non-hierarchy decision-making frameworic; 
Figure 16 is a block diagram of a digester line exdasapi&i 

Figure 17 illustrates a problem formulation for an optimization solution which may be created using die 
35 conqxnient architecture of die preferred embodiment; 

Figure 1 8 illustrates flexible dynamic optimization wfaidi may be perfDimed according to one embodiment 
of die invention; 

Figure 19 illustrates embedded data processing widtin an optimization solution; 
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Figure 20 iUustrates tiie maxmer in which procedures may be treated as models in one embodiment of die 
invention; 

Figine 21 illustrates the manner in which solutions may tntexact to provide an integrated decision- 
optimization networic; 
5 Figure 22 illustrates a basic exaxqple of a process being controlled; 

Figure 23 iUustrates the traditional prior ait approach to scheduling/optimization problems; 

Figure 24 illustrates an enterprise modeling/optimization system according to one embodiment of the 
present invention; 

Figure 25 illustrates a traditional production scheduling example according to the prior art; 
10 Figure 26 illustrates flexible scheduling according to one embodiraent of the invention; 

Figure 27 illustrates the macuLer in which diis embodiment of the invention may operate to control or 
enable flexible transitions; 

Figure 28 ilhistrates ^e manner in which dynamic models provide behavior; and 

Figure 29 illustrates ifae manner in which the system performs event triggered lo-^cfaedi^^ 
15 While die invention is susceptible to various modifications and alternative forms, specific embodiments 

thereof are shown by way of example in the drawings and will herein be described in detail. It should be 
understood, however^ that the drawings and detailed description thereto are not intended to limit the invention to 
the particular fonn disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and 
alternatives fiUling within the spirit and scope of the present invention as defined by the appended claims. 

20 

Detailed Description of the Embodiments 

Figure 4 - Exemplary System 

Figure 4 illustrates a simplified and exemplary view of one embodintient of a system according to the 

25 present invention. As shown, the system may include one or more con:4>uter systems 102 ^^ch interact with a 
process, system or enterprise 104 being modeled, optimized and/or controlled. The computer system 102 may 
r^resent any of various types of conq)uter systems or networics of computer systems which execute software 
program(s) according to various embodimBnts of die invention. The software program(s) may perform v^ous 
aspects of modeling, prediction, optimization and/or control of die process 104. 

30 As noted above, the process 104 may be any of various types of process, system or enterprise diat may be 

modeled, predicted, optimized and/or controlled, and element 104 is referred to generally herehi as a process for 
convenience. Exano^les of the process 104 inchide a mamifacturing process, a cbemical process, tiiiancial services, 
a supply chain process, an e-K:onimerce process, such as a business-to-consumer e-commerce process or a business- 
to business e-commerce process, a bnsiness-to business e-commeice marketplace, etc In the following discussion, 

35 die process 104 is considered to be a mann&cturing or automation process. However, this is not intended to limit 
the invention, it being noted diat die systems and methods described heroin may be readify used in perfommng 
modeling^ optimization and control of any type of process, system or enterprise. 

For example, with respect to a business-to business e-commerce maricetplace process, die computer 
sy5teni(s) may execute softwaro which optimizes various business transactions held in an electronic forum. 
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Tlius, die system and mediod may provide an environment for the decision making process of gathenng 
data, accumulating knowledge, and creation of models of the process for predictive modeling or control. The 
system and method may further provide an environment for making optimal decisions using an optimization solver» 
and carrying out those decisions, e.g., to control the enteiprise, which may be applied to a number of different 
5 applications such as automation, control, financial services, electzonic commerce, etc. 

The one or more computer systems 102 preferably include a memory medium on which con^ntBr 
programs accozding to the pzesent invention may be stored. The term "memory medium** is intended to mchide 
various ^es of memory or storage, including an installation medium, e.g., a <3>-ROM, or floppy disks 104; a 
ccn^uter system memory or random access xnemoiy such as DRAM,*SRAM, EDO RAM, Rambus RAM, etc.; or a 
10 non-volatile memory such as a magnetic medium, e.g., a hard drive, or optical storage. The memory medium may 
comprise other types of memory as well, or combinations thereof. In addition, the memory medium may be located in 
a first computer in which the programs are executed, or may be located in a second different computer which connects 
to the first computer over a network. In the latter instance, die second computer provides die program instructions to 
the first coinputer for execution. 
. 15 Also, the computer systBm(s) 102 may take various forms, including a personal computer system, noainfianie 

conq>uter system, workstation, network appliance, Internet appliance or other device. In general, die term **catapntex 
system" can be broadly defined to encompass any device having a processor which executes instmcdons fiom a 
memory medium. 

The memory medium preferably stores one or more software programs for perfonnii^ various aspects of 

20 modeling, prediction, optimization and/or control of die process 104. . The software pxogiam(s) are preferably 
implemented using component-based tediniques and/or object-oriented tedmiques. For example, die software 
program may be implonented using ActiveX controls, C4+ objects, Java objects, Microsoft Foundation Classes 
(MFQ, or other technologies or methodologies, as desired. A CPU or processor executing code aiul data l&om the 
memory medium comprises a means for creating and executing the software program according to the methods or 

25 flowcharts described below. 

Various embodiments further include receiving or storing instructions and/or data in^lemented in 
accordance with die foregoing description upon a carrier mediuizL Suitable carrier media inctode a memory 
medium as described above, as well as signab such as electrical, electrom^;iietic, or digital signals^^conveyed via a 
communication meHiiim such.as networks and/or a wireless link. 

30 One embodiment of die present invention provides a new architecture for providing software classes and 

objects or components for performing various aspects of modeling, prediction, optimization and/or control of a 
process, such as process 104. This new architecture utilizes a set of con:q3onent primitives which comprise reusable 
and configurable components that can be assembled in di£ferent ways to provide various modeling, optimization, 
contiol and decision solutions. Thus these components can be constructed or buflt in difTereht ways to provide 

35 different hjgher level solutions. Thus, the components can be applied as necessary to provide a modeling and 
opthruzation solution as appropriate for the situation or enterprise. Thus, the system does not include predefined 
high-level solutions like a scheduler, controller, estimator, etc. Rather, die con^nents are primitives that can be 
used to construct different types of lugh-level solutions such as these. 
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Figuie S - Component Arehitectuie 

Figure 5 illustrates the component architecture according to one embodiment of &e invention. The system 
comprises a flexible, distributed architecture conq>osed of configurable components. The architecture enables the 
development, dq)loyment» operation, and support of highly intcr-operable enterprise optimization solutions. The 
5 architecture of the present invention provides flexibility and modularity in deployment, execution, management, 
anrf visualization of modeling and optimization solutions. 

As shown, the component architecture may include a plurality of conqKxient architecture classes 122. 
Hiese base classes 122 can be used to mate or instantiate various con^nent objects 124, which are instances of 
the base classes. Further, new classes and/or objects can be created from this set of base classes 122 and 
10 component objects 124. The component objects 124 can be combined or used to create higher level objects or 
^plications. 

The component architecture may include a plurality of various object management tools and facilities such 
as global naming, storage and retrieval, cataloging and location, project grouping, deployment, revision tracking 
and visualization management The umfoim object management &cilities included in die system provide systematic 
IS management of project complexity. 

Figure 6 - Exemplary Object Classes 

Figure 6 illustrates representative examples of various of the component or object classes comprised in the 
architecture of the preferred embodiment As shown, the preferred embodiment may include different components 
20 or primitive object classes for modeling, visualization, simulation, optinoization '(solver), d^loymmt, execution, 
configuration, management, communication, rqpoxting and archiving, among others. These ccmiponents comprise a 
set of base classes fixmi i^ch various instances of these classes, or objects, may be generated. These instances 
may interact in an event based manner and may be combined to perform higher-level applications. 

The visualization and configuration components include a framework which provides web enabled access, 
25 enterprise wide access, on demand attachment, and view customization. Using the visualization and configuration 
components, tiie user can perfomi a variety of functions such as viewing historical data, monitoring debugging 
traces, monitoring decision engine execution, accessing solver diagnostics, locating and managing the decision 
engine, reconfiguring die deployed decision engine, and monitoring alarms and-events. 

For more detail on fte base classes comprised in die conqionent architecture, please see the document 
30 titled **Business Requirements Documenf* enclosed heiewidL 

Figure 7 - Encapsulated Decision Engine 

As shown in Figure 7, the various objects can be used to encapsulate the Decision and Optimiaation 
Sohition, i.e., the decision making process, as a "Decision Engme". The Decision Bngine may thus be an 
35 encapsulation of the knowledge and the decision making logic into a modular, portable, cooCigurable and extensible 
conqnnent The Decision pj^gwi^ may be an encapsulated component or object which has its own defined API. 
Hie Decision Engine may dius be a poruble conqxment that can be invoked in a variety of contexts, and 'Can be 
reused in difTereof applications. Figure 8 illustrates the manner in which die Decision Engine canoponent may be 
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created torn the various pximittve objects, and also illustrates the manner in which die Decision Engme component 
may be uscd as a modular component or object in a higher level solution. 

The component architecture of the preferred embodiment includes event triggered execution. In 
traditional prior art systems, execution is performed on a fixed periodic basis. As shown, the decision engine 
5 component and other conq>onent functionality may be invoked in various contexts and in response to various 
events. Execution of the decision engine may be triggered based on various events such as a synchronous clock, an 
external condition, a procednral step, or automation code, among others. Ihis flexibility allows the careation of 
powecfiil custom sohitions. 

The component architecture of the preferred embodiment also provides flexible deployment, wherein the 
10 modular decision engine component and other solutions created in the architecture of the present invention may be 
deployed in a variety of execution contexts. Exanqsles of where the decision engine component may be employed 
include a web client/web server environment, a workstation application and an application server. 

Figure 9 * Unified Approach 

15 Figure 9 illustrates tiie graph of Figure 3, but having ihc approach used according to one enbodiment of 

the inventioxL As noted in die background section, in ibis graph the X axis represents the process and decision 
type, where flie values along the X axis vary from continuous processes at the origin, to batch processes as X 
increases and then finally to discrete processes. The Y axis represents the scope and resolution of the decisions 
being made. At the origin, the scope and resolution of the decisions are local involving very simple decisions, and 

20 as Y increases, decisions become more coizq>lex until at the highest point of the Y axis the system involves 
planning tiie strategy of a whole enteiprise. 

As shown, the conaponent architecture of tiie present invention allows different decision making 
components to be applied and spread across this 2-dimensional space. This leverages the commonality that is 
found across these two axes, ratiier than focusing on the differences between them. The present invention tiius 

25 provides the framework for various different solutions. 

Improved Modeling / Opttmization Methods 

Various embodiments of the present invention include techniques for optimizing enterprise operations, 
such as manufacturing qserations^ e-commeice operations, business-to-business e-commeice systems^ etc. These 
30 techniques are described below witii respect to manu&cturing processes, but may be readily an>lied to any of 
various enterprise systems, such as those mentioned above, among others. 

Distributed Evcnt'Driven Component Architecture 

The underlying architecture of the present system is structured to sappoxt the modularity, flexibility, and 
35 scalability needs of nirnble enterprises. Components are designed witii plug-and-play modularity to allow 
substitution with better tedmologies, as they become available. Business functions witiiin the ardutfictme may be 
replaced witii odier functions on a coinponent*by*con^nent basis with minimal, if any, negative inqaact to oftier 
business functions. 
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Txadidonal software developmeat has integrated some of these capabilities into a sii^le monolithic 
system; however* re-use of modules becomes impractical. Even worse, some software products consist of isolated 
islands of functionality with very limited interoperability. In the preferred embodiment of the present invention, 
these functions are components of the architecture but are not dependently integrated. New modules can be easily 
5 added diat extend die core functionality widioiit replacing die whole enteiprise solution. 

Components represent discrete, independent system functions that p c ffam a. a single business functicm. The 
components are reusable and are combined to form modules in support of a specific business process; Ihey can be 
combined, disassembled, recombined, reused, added, and replaced to support chaise. They standardize the 
functionality of each basic business function. Through the reuse of the components, redundancies are removed, and 
10 system processes are assembled in a consistent manner. A comprehensive series of conqKments for business and 
specific industries is delivered. Each has a parameter configuration layer to facilitate incorporating client-specific 
processing requirements without requiring custom software. 

The system and method of the present invention contains general tools leveraged by all con^nents such 
as modeling tools, decision engines, rules-based explanations, and run-time engines. The present system also has 
15 flexibility in dealing with data sources, data transformations, currency convmions, and multi-platform processing. 

Architectural support is provided for the bonding of reusable components. Rather than crafting an -entire 
application each time a new process is needed, the present system facilitates die assembly of new business 
processes from existing business con^onents. 

Under this architecture, processing (preferably all processing) is initiated by an event An event is the 
20 specific occurrence of a process, originating eidier internal or CTctemal to the system model. An event can be 
generated through human action or by an automated process. The occurrence of any ^en event will often become 
die trigger for initiation of odier events. The solution to any business problem, then, becomes a series of 
interrelated events. 

Within the system, an event is the result of a specific ta^k such as successfiilAinsuccessful, true/£alse or a 
25 mm^c task type assignment to select one of a series of options. Events typically have additional tasks to be 
performed based on the result. These associated tadcs will also produce results and will be classified as events of 
their own. This consequence processing is "what allows entire business processes to be built fiom individual events. 
Any number of events can be created within the system to allow for the processing of any necessary scenarios. 

Business enterprises generally interact with other business enterprises, such as-customeis, suf^hers, and 
30 distributor. As shown in Figure 10, diese interactions are represented in the present system as events in a maimer 
consistent with internal events. Each event, whedier internal or external, is tagged with appropriate identity 
information suitable for auditing, genealogical, or other purposes. Thus, events may span enterprises. 

Synthesizing Batch and Continuous Processing Frameworks 
35 In one embodiment, the preset invention includes an tnqmved system and method for modeling, 

<^timization and control of batch and continuoiis processing fiameworks. 

Manufacturing processes have traditionally been broken down into two primary modes of operation: bateh 
and continuous. A batch process is one in which a series of operations is conducted over a finite period of time on a 
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discrete, identifiable, and traceable lot of materiaL A continuous piooess is one in which operations occur 
simultaneously on a stream of materiaL 

Batch processes provide flexibility for producing multiple products in relatively small quantities. In many 
instances batch processes are necessary because they provide the environment required to achieve the physical and 
5 chemical conditions to perform a specific task. For exan:q>le, fermentation requires a controlled condition for an 
extended period of time. Batdi processes make this possible and are a more flexible solution when compared to 
continuous processes. Although die batch and continuous modes of operation are fundamentally dififereht, the 
overall objective of each is essentially die same: lo convert raw materials into desired products in die most 
economical way. 

10 In addition to fundamental differences between batch and continuous manufacturing, the corresponding 

automation solutions have fundamentally distinct characteristics. Continuous automation solutions are chaiacterized 
by feedback data-flow structures. Batch automation solutions are characterized by event-driven sequences of 
procedural instmctions. 

Any actual manufacturing process has elements of bodi continuous and batch processing applied at 
IS different levels. In managing a continuous process, it is necessary to perform such tasks as startup, shutdown, 
transitions, and grade changes. These tasks have a batch-like nature. Likewise, regulatory and advanced process 
control applied during a batch operation has a continuous nature. In addition* many processes themselves have both 
batch and continuous processing steps. 

Given that a complete aatomation solution requires bodi continuous and batch mediods, the present system 
20 includes a framework ttiat seamlessly blends event-driven procedural logic and data-flow structures at all levels of 
the enterprise. 

Hybrid Model Representations 

Optimal decision making requires appropriately constructed models that accurately describe the behavior 
25 of the system. In general, there.are two ways to describe the behavior of a systm: 

First-principles Model - A model whose internal mathematical representation is based on an 
understanding of die physical processes diat occur withm the system. These knowle4ge-based models are also 
referred to as fundamental models. 

KmpiWcal Model - A model tliat captures (he tnput/ou4)ut behavior of the system based on measured data 
30 without relying on knowledge of die physical processes diat occur within die system. 

Hiere are certain advantages and disadvantages associated with each of these modeb. 

First-principles models are usually more accurate and can extrapolate better. They also provide a physical 
understanding of the process, which is indispensable for design purposes. Empirical models are applicable as long 
as appropriate data is available. Ibey ai^ however, limited to the quality and extent of that data. Empirical modeb 
35 are often &ster and easier to construct and can typically operate at much foster processing speeds. 

In immerous ^iplications, first-principles and empirical models atone are not sufiBcient for proper 
description of die problem at hand. To compensate for the lack of information, often-conservative decisions are 
made to ensure fail-safe operation. Batch processes in particular are known to be prone to diis problem (Le. oileo 
first-principles kiuiwledge of the process is not conq)letely available^ and the available data alone is not rich 
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enough). In feet, the development of effective advanced control algorithms would be enhanced by tbe ability to 
leverage the advantages of both model lepresentations. 

Empirical modeling has been used to control many sophisticated nonlinear processes. One embodiment of 
the present invention provides die following capabilities to meet the technological challenge that a systematic 
S decision-making process presents: 

Con^osition - Provide encapsulation and composition of dsffertot model types. For example, if dieze is an 
emp mcftl model for one unit, and a first-piinciples model for anodier unit, enable coheieat inclusion of ftese 
models into a combined model to allow for unified optimiTation. 

Training — Use of fibrst-principles information (including any expert knowledge) to complement the 
10 available data during training of an empirical model. The resulting empirical model reconciles the information 
available from process data and expert knowledge into a computationally manageable fiamewoik. Hius. leal-time 
decision-making in a batch operation scenario becomes numerically feasible. 

Parameter Identification - Use of nonlinear, empirical modeling techniques to identify parameters of fitst- 
jsrinciples models based on measured data. This facility provides paiametric identification for representations other 
IS than pure data-fitdng forms. 

As shown in Figure 1 1» the system and method of this embodiment includes a unified modeling frameworic which 
unifies the various types of models such as first principle models, also referred to as fundamental models, empirical 
models and procedural / recq>e models. In many processes being modeled, the process does not completely ^confoim 
to a single model type. Rather, the process may have elements of several model types. Thus this embodiment of 
20 the present mvendon allows different model types to be used together for to more correcdy represent these types of 
hybrid processes. This provides more flexible modeling services dian have existed in the prior art 

Figure 12 ilhistrates an exanq>le of model aggregation according to one embodiment of the invention. As 
shown. Figure 12 illustrates that heterogeneous combinations of model conqyonents may be aggregated together. 
This encapsulated aggregate model, vdiich may conq>rise models of dififerent types, may then be treated itself as a 
25 model. The encapsulated aggregate model is a modular and reusable component which can be used with various 
other objects, as desired. 

Thus, one embodiment of the present invention provides a unified modeling firamework which allows a 
user to aggregate different model representatioiis for the different pieces of die system. Ihus, the models chosen 
may be a mixture of a neural network and various other enyirical or fundamental modeling types. 

30 

Flexible Dccision-Makiiig Hierarchy 

In another embodiment, the present invention includes an inqnDved system and method for flexible 
configuration of the decision-making hierarchy. 

The traditional operation of an enterprise is coxoposed of a hierarchy of decision-making activities that 
35 include such generic tasks as planning* scheduling, optimization, and control The hierarchical separation of diese 
ftagVg corresponds closely with human roles and responsibilities widiin the TnanAif?'^'""g organization. High-level 
decision blocks encompass long-term goals of die enterprise and address a broad scope of operadons. Low-level 
decision blocks cover shorter time frames and narrower scope, such as die actual execution of actions on die plant 
floor. 
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The sqpaiation of tiiese decisLon-maldng elements serves two puiposes. First, tt provides a divide-and- 
conquer strategy rendering the decision-making pfocess tractable. Second, it isolates tasks tbat have •difierent 
processing needs and different problem representations. 

Figure 13 illustrates .two exan^les of sudi decision-making hierarchies. The first is typical of batch 
5 process automation; the second is typical of advanced process control and optimization, for a continnous process* 
Clear^, tfie division of tasks is not unique, even witfiin the manufocturing executioa layer. Furtheimoie, given diat 
the problem characteristics vary considerably within a level, it is apparent ttiat no single solution can apply to all 
operatioss. 

Rather than force-fitting a single solution to all organizations^ a more powerful approach is to provide a 
10 framework that allows the flexible combination of modular decision-making components. This approach allows 
the automation solution to match the requirements of the business more efiTectively. This framework also facilitates 
rapid, efficient restructuring of the conq>onents as the business needs change. 

A modular decision-making hierarchy can be described by first abstractuog the conmion elemeots within 
various hierarchies and then blurring, or even eliminating, tfie distinction between traditional layers. This is 
15 illustrated in Figure 14. 

As shown in Figure 14, each level of die abstracted decision-makiiig hierarchy exchanges information widi 
die levels above and below. From the perspective of level directives are received from higher level unit A sach 
as valve settings, targets, product specificatioois, or schedules. The characteristics of die xnfoimation depend on the 
type of decisions to be made at that level. Actions determined at level B are sent to level C. For example, a tank- 
20 level controller receives a target fluid level from an optimizer every ten mirmtes and relays a sequence of valve 
settings to the control hardware every five seconds in order to maintain the tank at that target level 

The corresponding upward flow of measurement information from C to Jl serves several puiposes. First, it 
prov&les feedback about how C has responded to the siqiplied actions and can be supplied either periodically or as 
exception events. Second, level C conveys constraints to level B, such as valve position limits. Third, level C 
25 provides a simplified model of its behavior in order to improve the decision-making process of ^. This third piece 
of information is critical for tightly integrating the decision-making hierarchy while maintaining modularity of die 
mdividual levels. 

The coordination backbone link is necessary to integrate tasks that operate under dififeient execution 
met^ihoxs. For example, if level A operates in a daily transactional environment and level B operates in real time, 
30 the coordination backbone synchronizes Oieir execution. Moreover, the backbone will provide necessary data- 
translation services. 

Given this abstraction as a basis, various decision-making components can be developed that will plug- 
and-play widiin an overall framework. An important requiren:ient of diis structure is to allow blurring between 
traditionally distinct levels such as scheduling and control. Appropriately-designed information exchange between 
35 components will allow one level to incorporate the dynamic behavior of die lower levels widiin its decision-making 
process. U.S. Patent No. 5,S^3,34S describes a system which demonstrate how die seamless integration of steady- 
state qptunization and model predictive control — traditionaDy distinct sub-systems— results in a world-class 
solution. The framework expands the opportunities for developing and integrating such synttiesized solutions. The 
real-world examples in Section 4 illustrate the value provided by such xntegrated solutions. 
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It is in^xtant to distinguish this architectural approach from two distinctjextxeines. 
The first extreme would be to supply a stock planner, scheduler, optimizer, advanced process controller, 
and regulatory controller while leaving integration as an engineering exercise. This has been the traditional industry 
approach and significantly limits the capabilities of the delivered solution based on forced isolation of the decision- 
5 T^iilciqg components. 

The other extreme would be to formulate die entire decision-making problem using a single representation 
and solving it as one unit This would require tfiat an organization foice-A its operation into a rigid, inflexible 
stmctuxe that did not accommodate ^namic business strategy. Furthennore, it is unlikely that Khe resulting problem 
fonnnlation would be either solvable or practical to maintain. 

10 Clearly, flexibility in choosing from a spectrum of decision-making strategies provides businesses the 

abilit/ to make more appropriate use of information resulting in improved performance and profitability. 

Previous discussion assumed diat the decision-making process, although flexible, is still smictured as a 
linear hierarchy; this need not be the case. For example, multiple aspects of die organization might contain 
interdependent yet distinct decision-making processes, integration of these systems might require further 

15 generalization of the decision-making structure to encompass networks of inter-communicating components as 
illustrated in Figure 15. 

More important, this network will not necessarily remain fixed over the life-time of the organization. Not 
only wiU the structure evolve as the goab of the business change, but the structure may also change dynamically in 
response to events internal or external to the organization. This flexible framewoik allows dynamic reconfiguration 
20 or selecticHL among sets of configurations in response to unexpected events. 

Examples 

This section describes a series of examples that illustrate certain aspects of various embodiments of die 
present invendw. 

25 

Pulp Mill Batch Digester 
I. Current Ajyproach 

In the paper wmirmg process, wood ch^ are broken down into pu^ at &c pulp milL The customcr*Opapcr 
miU) sets the pulp production requirements in die number of tons pex day of pulp, both hardwood and pine. At the 
30 pulp mill, wood chips are mixed with 'iiquor^ and "cooked" in vessels called batch digesters. The digesters are 
heated witib steam, pressurized, and the chips are "cooked.'* When die reaction is complete, the contents are 
released, or '^lown,'* into a holding tank, and a new batch is started. Only one digester can be released at a time. 
The quality measurement of whedier the pulp is finished cooking is called die Kappa number. Figure 16 is a 
diagram of the process. 

35 At the begiiming of a batch, the q[>ecator can speed up the cooking time by adding more steam. Adding 

more steam will increase production at the cost of product consistency. The availability of steam is a constraint 
.Slowly adding steam gives a more consistent product and better upstream boiler operations. Once the cooldng 
temperature is readied, the reaction cannot be slowed down or stopped. To mfllntarn product quality, ^ digester is 
released, or blown, within a finite amount of time when the Kappa number is reached. If the operator has to hold a 
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batch that is ready to blow, it will continue oookiiig and tfiece will be a variation in the Kappa number. This 
variation causes problems in die paper machines downstream. The availability of steam, pulp production 
requironents, and product consistency are all constraints to this process. The Kappa measurement is taken after ttie 
process is complete ox can be estimated with a model while the batch is cooking. This Kappa estimate he^ die 
5 operator know when it is time to blow a digester and helps the operator estimate when a bateh is done. Over- 
cooking and under-cooking occur with upsets in steam and poor scheduling <e.g. two digesteis need to blow at the 
same time). When upsets in steam delivery occur* die batch schedule needs to diange dynamically to meet tihe 
quality and production requirements. Steam should not be demanded or cut too quickly, or else an upstream upset 
will occur at the boilers. Hardwood and pine have dififerent cooking times. These dynamic requirements and 
10 constraints are more than the pulp mill operator can manage easily. 

Unified Solution 

Combining the ability to predict and control die Kappa number'with a dynamic schedule and the abiUty to 
control a batch during the cooking phase provides die following: 
more consistent product, 
ability to handle steam upsets, 
more stable upstream boiler operations, 
better utilization of capital equipment 

Software that optimizes the batch digester schedule and operations has a tremendous impact on the 
company^s profitability. 

Unified Automation System for a Polyolcfin Plant 

AMiough operated contiimously, polyolefin plants generally produce different grades of resin at different 
times. A polyethylene plant always produces polyethylene; however die resin used for making milk bottles is 
significandy different fiom that used to make garbage bags. The basic specification which distinguishes the grades, 
called Meh ladex (Nfl), is related to the length of the polymer chain, and can be compared to viscosity. The plant is 
operated very differently to produce each-grade. The act of changing the line to move between.gmdcs is commonly 
called a transitioiL Ttansitioos coimnonly .generate resin, which cannot be sold as either the starting or ending 
grades and must be disposed of at a loss. The -economics of all polyolefiua plants are dependent upon how transitions 
are managed. On average^ diere is one transition a week at each line lasting from 4 to over -24 hours. Lost revenue 
per transition can be $5,000 to over $40,000. Consideiable software, manpower, and monetary resources are 
enq>loyed to effectively manage resources. There is, however, much room for improvement 

Current Approach 

35 In die current prior art approach, die first step is to schedule the difTerent products in time to meet the 

customer demands for volume purchased and promised time-of-delivery. In addition to die customer demands, 
stock in inventory and transition costs are consideied while determining die schedule. The transition model is a 
fixed matrix of average transition times between eadi possible combination of products, ^ome co mbinatio ns axe not 
aUowed. For example, the transition matrix time for a 4 MI to 8 MI transition may be 4 hours while a transition 
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from 0.8 MI to 20 NO may be 12 houns. The actual transition time under current conditions is not considered. 
Generally the inventory is increased to arbitrarily high levels so that Uie schedule becomes a wheel — products step 
up from low to high Ml then back down, always moving between adjacent products. This scheme is obviously sub- 
optimal and does not allow for the best ability to promise delivery dates. 
S Once ttie schedule is set, the transitioa must be execoted. Two systems are employed for dus, the 

operations petsomiel and the control systentL First die transitioa path must be selected. There are multiple ways to 
efifoct a transition. The line can run at full capacity and at Ml inventories v^iile rapidly changing tiie reactant ndx to 
the new product This mechanism is usually fast but results in a large volume of transition, or off-grade, material. 
Alternatively, die line can cease production and empty all in-process inventory while on-grade with the current 

10 product, change the reactant mix while the reactor is empty and not producing, and then re-start the Une and build 
the in-process inventory. This strategy has Utde off-grade production, but takes a long time with nothing produced. 
Although these options represent two extremes, there are infinite possibilities in betweerL An optimizatian engine 
does ru>t decide die best path. The operation staff chooses based on experience and intuition. 

Finally^ die transition is executed based on the operator's goals by the control system. Expert systems and 

1 5 advanced control systems are occasionally used to facilitate die tcansitian. 

Unified Solution 

A combined scheduling, optimal path selection engine, sequential and contiimous control automation 
system is desired. The schedule and transition path optinuzation is preferably solved simultaneously using bodi the 

20 actual plant models and the currendy relevant economics, including the cost of inventory. Then the transition path 
may be executed consistendy according to plaru A comibined sequential and continuous control system with 
continuous optimization is used for this step. The schedule and path selection can execute in real-time, and the 
results can be automatically downloaded to the real-time sequential and continuous optimization engine. With such 
a system, inventory levels can be reduced while simultaneously breaking '^product whccr*-typc scheduling to 

25 become more responsive to customer demands. Because die entire system executes rapidly, optional delivery times 
and prices can be quoted based on an accurate calculation of operating costs. Finally, because the ^tire system is 
fully automated, these quotes could be delivered via e-business vehicles. 

Figure 17 - Problem Formiilation for an Optimizatian Solution 

30 Figure 17 illustrates a problem formulation for an optimization solution which may be cre ated using the 

coiiq>onent architecture of the preferred embodiment As shown, an optimization solution may be created including 
a solver, a problem formulation, and a dynamic process model The dynamic process model is an internal model of 
the process wtdch enables prediction of how die process will re^ond over a period of time. Given a particular 
formulation of die problem, various solvers (or optimizers) may be applied in order to optimize how the process 

35 will behave over a liorizoiL This may be used to determine what control actions should be sent to the process to 
achieve a desired result 

As shown, each of the solver, problem foTmulation, and dynamic process model may comprise differem 
modular phig and play con^nents which may be created using the oon^Mment architecture described above and 
wknch may be readily used or inserted to provide diiferent sohitioiis. 
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As shown, &e dynamic process model conq>nses a modular component or object which may be any of 
various types, such as a first principles or fundamental model, a linear model, or a nonlinear model such as a neural 
net model As noted above, the dynamic process model con^>onent may also be comprised of a hybrid model using 
(he unifomi modeling fi:amework described above. Thus, the dynamic process model may be a component or 
5 object which represents two or more dififeceni model types, e.g., a first princq>les model and an analytic model 
which are combined (ogelfacr to create a single model object or component 

The solver may also be a modular conqKment or object, and as with the process model object, different 
solver objects or components naay be inserted into die solution as desired. As shown, tbe solver object or 
cftfTtpongnt may comprise a nonlinear pragramming solver, a mixed integer nonlinear programming solver or an 
10 evolutionary solver, among others. The solver object may also be referred to as an optimization object 

The problem formulation may also be a modular plug and play component or object which may be 
inserted into various different solutions. As shown, the problem formulation may take various forms, such as 
predictive regulatory, steady state, and batch tr^ectory. The problem formulation may also have both batch and 
regulatory control fonmilations. 
IS Thus, the user may utilize different solver, problem formulation, and dynamic process model objects or 

conqKments in a modular and reconfiigurable plug and play manner to create different solutions. This allows a 
much more flexible and power&l inechanism for creating optimization solutions than that existing in the prior art. 

Figure 18 - Flexible Dynamic Optimization 

20 Figure 18 illustrates flexible dynamic optimization which may bet performed according to one embodiment 

of the invention. The system allows flexible dynamic optimization for different horizons. As is well imown, a 
shrinking horizon refers to the notion in batch processes where the horizon time period in which tfie resuhs of 
actions may be seen ends at a certain point in time, e.g., when the batch has completed. In contrast, a receding 
horizon may occur in a continuous process and presumes that the results of actions may be reflected over a lengdiy 

25 or even infinite time period. As shovm in Figure 18 the graph illustrates two exan^les of a prediction horizon into 
the future. The vertical line contained in the graph illustrates where the process currently is in time. The portion to 
the left of the vertical line iUustratss what the process has done in the past The lines to the right of vertical line 
in Figure 18 represent a possible control action which may be provided to the process and die predictions of how 
1tc process wiU react in response to this control action. The graphs ttras provide a visual metaphor presenting how 

30 the optiinization solution is performing over tiine. 

Prior art systems typically only allowed a predicted fixed set point to be set, herein control actions may 
be provided to attempt to reach this fixed set point However, according to one embodiment of the invention, the 
user is able to provide a continuous or discrete line indicating a desired result by configuring constraints and targets 
as trajectories instead of a single set point Thus, die user can indicate that the temperature should foUow a certain 

35 trajectory into the lumre and die user may dien be able to c^timize the profile of die tenq;>ezature on a respective 
batch. Thus, as shown, the flexible dynamic optimization allows dynamic predictive control over both a shrinking 
horizon for batch phase trajectory control and a receding horizon for set pomt regulatiozL 
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Fipne 19 * Embedded Data Processing 

Figure 19 illustrates embedded data processing within an optimization solution. As shown. Figure 19 
illustrates that pre and post processing functions may themselves be encapsulated as respective conq^onents or 
objects. These compoacats may be combined with odier objects, e.g., a decision engine which may include one or 
5 more of a solver, problem formulation and process model, to oreate a more complete solution. Thus* a pre- 
processing object may be created, wherein the pre-processing object may comprise a configuiable, modular and 
phig and play component which may be combined in various manners with the various different decision-engines. 
In a similar manner, a post processing function may be encapsulated as an object or CQn:qK>nent which may also be 
combined with difierent combinations of decision engines. This allows a more modular and configurable 
1 0 mtehanism for developing Qomplete modeling, optimtzatiDn and control solutions. 

Figure 20 - Procedures as Models 

Figure 20 illustrates the manner in which procedures may be treated as models in one embodi n a e n t of the 
invention. As shown, a flowchart or procedure may itself be treated as a model component This procedural model 
15 component may itself be treated as a "procedural sub-model", wherein die sub-model may be combined widi odier 
model types to create a hybrid modular model con^nent As shown, procedures may be treated as models in 
various applications such as batch recipe execution, APC management, diagnosis and error recovery, and expert 
system decisions. 

20 Figure 21 - Solutfons Interact widiin Framewoik 

Figure 21 illustrates the manner in which solutions may interact to provide an integrated decision- 
optiraization network. As shown, solution A may comprise a model as well as other components, e.g., a solver, 
constraints etc. which provides actions and objectives to control a second solution B. The second sohition B may 
itself have a model and other con^nenls which may further control another solution or the process or enterprise 

25 being modeled or controlled- As shown, since solution A affects the operation of solution B, it would be desirable 
for solution A to dynamically understand or have knowledge of how solution B will respond to the actions provided 
by solution A. Therefore, as shown, in one embodiment of the invention a model of a solution can also be 
contained within another sohition. Thus, a model of solution B may itself be con^rised in solution A, so that 
solution A may use the model of solution B in determining the actions to provide to solution B. As shown, solution 

30 B may also provide translated results including operating point constraints and the model of solution B to solution 
A for this purpose. This thus provides an integrated decision-optimization network which provides more intelligent 
solutions dian available in the prior ait 

Separable ModelsAJser Interface Components 
35 Another important aspect of the architecture of one embodiment is that an application or solution may 

•have a separable modular user interface which is sqiarate ffom the decision eogine controller or modeL Thus, die 
deployable conqmnent e.g., die decision engine is separate ficom the user inter&ce component Thus, different user 
interface coiiq>onents can be attached to tiie deployable con^ionent or solution in a modular ^ishion. Thus, the user 
may select among various different interfaces and change various different inter&ces in a modular fashion as 
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desired. Thcicfoi'c» users can select different types of user interfaces for a sii^e deployabie con^onent, such as a 
textual description, a graphical descrq>tioii, and use with buttons etc. 



Figure 22 - Process Control Example 
5 Figure 22 illustrates a basic example of a process being controlled. More specifically, Figure 22 tltuslrates 

a polymer production exanqile wherein a reaction line produces various plastic grades to inventory based on 
scheduled needs. As shown, raw materials are applied to a process. The process may be either continuous or batch 
or may have aspects of botii continuous and batch. For example, ttie process may have a continuous reaction 
process and on-grade control as well as batch charactetistics of lot handling and configuration automatiorL As 

10 shown, &e process may utilize the raw materials to produce various plastic grades such as car bumpers (hard)» milk 
bottles (medium), and diapers (soft). 

Iq prior art systems, production scheduling and production control have traditionally been isolated layers. 
Production scheduling involves meeting deirumd, meetixig delivery dates, and managing inventory. Production 
control involves maintaining product quality, mnwitaining product consistency, operating efficiently, rmnaging 

15 production transitions, and maruigiiig unexpected disturbances. Where production scheduling and production 
control are isolated layers, these layers are unable to properly coxmnunicatB widi each other to produce an optimal 
enterprise solution. 

Continuing with ^e example, the process line makes dififeient grades of plastic at different times. The 
plastic conqsonent is produced and sent out to inventory and stored in different bins. When the customer makes an 
20 • order, the business offer causes the triggering of some of this inventory to be slupped out to the customer. In order 
to avoid having the inventory be err^ty when a customer makes an order, often times die prior art (isolated) 
scheduling component would over fill the inventory in order to ensure that client demands can be met Thus, the 
^ scheduling component would typically be very conservative about managing the inventory. The traditional disjoint 
method of solving this problem with separate scheduling and control layers provides an inadequate method of both 
25 scheduling and control, since each con:^nent caimot communicate with each other to provide necessary 
information needed by each for a more intelligent solution. 

Figure 23 - Traditional Approach to Scheduling / Optimiaation 

Figure 23 illustrates the traditional prior art approach to scheduhng^optimization problems. As shown, and 

30 as noted above the prior art approach has typically used an "^islands of technology" approach comprising separate 
applications, e.g., a separate scheduler application, separate optimizer application, and separate controller 
application. As shown, the scheduler application conununicates with the optimizer application which in turn 
communicates with the controller application. The controller communicates with the process line to control the 
process being perfbrmed. Some of the drawbadcs with this traditional ^)proach is that each of flie scheduler, 

35 . optimizer and controUer caimot take advantage of aD of the enterprise data which would be desirable to optimize 
the entire enterprise. For example, the scheduler could not utiHase iirventory data in any type of real time fashion 
and also cannot utili2se business system data. Thus, this traditional approach lacked an enterprise-wide view of the 
systenu Further, tiiese separate plications typically do not conmmnicate with each other adequately to form an 
enterprise solutioiL 
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Figures 24 * 29: Process C rdinator 

Figures 24-29 provide a description of an integrated process scheduling solution referred to as process 
coordinator. In one embodiment, process coordinator is designed as a manufacturing automatioa application Ifaat 
5 seamlessly incoipoiates the capabilities of advanced process control and recipe executian into a real time event 
triggered optima] grhg^^iiing solution. The process coordinator of fliis embodiment includes a number of 
innovations, including schedules based on real time information, unification of scheduling and controlled tasks, and 
blending of batch and continuous representations. 

The process coordinator system of one embodiment of die invention operates to combine scheduling and 
10 control into a powerful hybrid environment This operates to provide a more enterprise-wide view of the complete 
solution or system, enabling more intelligent scheduling and control since each of these layers understands the 
operation and needs of the other layer. Therefore, in the example of Figure 22, scheduling would mvolve 
determining how much of a certain plastic conqx>nent to make and at what time the plastic component should be 
made in order to meet customer demands, e.g., how many of the hard plastic is produced versus how mudi of die 
15 soft plastic is produced. The control task would involve actually controlling the production unit or process to make 
the chosen plastics to ^e right quality, right consistency and maintaining efficient operations, etc. As noted above, 
' these two operations or decision/automation solutions were traditionally done almost in complete isolation. The 
process coordinator system of this embodiment operates to combine these into an integrated fashion, which allows 
much more intelligent scheduling and control 

20 

Figure 24 - Enterprise Modeling / Optimization 

Figure 24 illustrates an enterprise modeling^optimization system according to one embodiment of die. 
present inv«ition. As shown, this system includes a process coordinator which is compised of or built of a 
plurality of primitive components. The primitive components represent building blocks used to create a 
25 modeling/opdmization system. As discussed above, diis building-block architecture enables the creation of a more 
integrated and enterprise-wide modeling/optimization system. As shown, the process coordinator, according to this 
embodiment; coxmmmicates with tiie process line inventory data and business system data to provide a more 
completely optimized enterprise-wide system. 

30 Figure 25 - Prior Art Production Scheduling 

Figure 25 illustrates a traditional jnroduction scheduling example according to the prior art Figure 25 
illustrates a production wheel for the above polymer problem. As shown, different grades of material are being 
produced at different times for different lengths of time. The scheduling problem has traditionally pre-assumed tiiat 
die sequence win appear as an *'oscillatixi^ wheel of production**, and die only variables are the lengths of each of 

3S file production grades. The lengths of the production grades comprise how much.pcoduct is made of fiiat grade, 
e.g., how long die grade is made. A sequence list is typically maintained which indicates the grades to be produced. 

As shown, a controUer controls the plant in performing die transition &om one .grade to another. The 
behavior of the transition between grades is a function of both the process refuse and how the process is being 
controlled However, knowledge of only the process response is inadequate to understand how fiiat transition is 
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going to occur. In general a model of any control strategy that is being applied to that process may be needed in 
order to properly understand the transition. Furthcnnore, the control strategy may be changing over tiniB based on 
operating conditions. 

In prior art systems, the scheduling problem is traditionally performed with a static fixed cost matrix 
S ^i^iich defines tfie cost for a transition firom any grade to any other. The scheduling problem finds the optimal 
lengths to meet demands subject to die cost associated with these transitions. However, these costs in the static 
fixed cost matrix are typically inaccurate and outdated, since they are typically generated a lengdiy period of time 
prior to fheir use, e.g^ 3 months ago. 

10 Figure 26 - Flexible Scheduling 

Figure 26 illustrates flexible scheduling according to one embodiment of die invention. As shown, the 
process coordinator allows flexibility in production order, which may provide inqiroved reqnmse to customer 
requests and more effective management of inventory. 

One embodiment of the present invention opetates to perform the scheduling optfanization problem using 
. IS leal-time modeled cost infoimation about how that tnmsition will occur and the associated costs. Thus the system 
uses a model of die physical process, and a model of the control strategy, wherein the models include sufficient 
detail in oider to be able to predict how the process will behave during transitions. The behavior of the process 
may be a mix of continuous and/or batch type of automation characteristics. Therefore, in one embodiment, as 
discussed further below, die system includes a modeling firamewodc that subsumes both, Le., that handles both 
20 continuous and batch characteristics. Thus, ttie system includes one modeling fiamewoik for bodi forms of 
modeling. 

Thus, as described above, xeal cost infomation is used in performing (be scheduling. In addition to this, 
the system and method can optimize the padi itself as well as optimizing the order in which products or grades are 
produced. Thus the system can solve a combined path planning problem and scheduling problenx 

25 In prior art systems, scheduling is performed with no knowledge of how the control is perfomied. In tiiese 

prior art systems, die system must be vccy conservative in scheduling because the system can not capture the details 
of how die control system will actually respond. In the system described herein, scheduling and control functions 
are integrated, and the system can be much more aggressive about scheduling. As described fiirdier below, the 
scheduling solver may include an embedded model of die layer or model below, and the scheduling order may be 

30 updated as necessary based on this embedded model. 

Thus the system operates to solve the scheduling problem subject to various types of dynamic constraints. 
Therefore, by integrating scheduling and control fimctions, the system of the present invention can perform more 
advanced modeling and optimization. 

35 Figure 27 - Flexible Transitions 

Figure 27 illustrates the manner in diis end)odiment of the inveatioit may operate lo control or 

enable flexible transitions. Figure 27 illustrates two gr^hs of melt index or grade versus time. As shown, widi 
iitftTtiifli control, poor transitions may occur. As noted above, this embodiment may operate to combine noxilinear 

20 
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optimization and control and thus enable laige rapid consistent transitions necessaxy for flexible scheduling. Thus, 
ttie control used according to this embodiment provides fast consistent transitions. 

Figure 28 - Dynamic Models Provide Behavior 
5 Figure 28 illustratBS the manner in which dynamic models provide behavior. Figuxe 28 also illustrates a 

graph of melt index or grade versus time. As shown, unified dynamic models allow the process coordinator system 
to compute optimal decisions based on accurate costs, constraints and predicted impacts. The system utilizes 
dynamic models of one or more of physical process, control strategies and business context 

10 Figure 29 - Event Triggered Re-Scheduling 

Figure 29 illustrates the manner in which the system performs event triggered rescheduling. As shown, the 
process coordinator system may operate to re-schedule grade production based on requests from priority customers. 
Thus, the process coordinator system may operate to abandon a previous schedule and adopt a new schedule based 
on production requests received from customers. Thus, downstream sdieduliog may be le^timized based on diis 
15 real time informatioiL Furtfier, the actual inopact of this custorner request fiilfillmeat is kno 

Therefore, tike process coordinator system of this embodiment reduces production costs and inventory, 
enables dynamic customer response, can respond to unexpected events, and can compute accurate pricing and 
delivery time. Thus, the system leverages the flexibility of production assets. 

20 Conchision 

The system of die present invention establishes the architectural finmewodc for a plurality of enterprise- . 
wide optimization products. This enterprise-wide solution combines aU relevant information across the enterprise 
in order to make optinud decisions. The architecture is open, extendable, modular, scalable, maintainable, and 
rapidly re^configurable. 

- 25 Altiiough the system and method of the present invention has been described in connection with the 

preferred embodiment it is not intended to be limited to the specific form set forth herein, but on the contrary, it is 
intended to cover such alternatives, modifications, and equivalents, as can be reasonably included widiin ttie spint 
and scope of the inventicKi as defined by the appcDdcd claims. 
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1 . A method for enabling a user to create a program for controlling a process, wherein the method 
operates in a system including a computer system which is coupled to the process, the method comprisiog: 

S providing a pluxality of software classes for mo<lieUng, optimizatioa^ and deployment; 

providing one or more management facilities for managing die plurality software classes 
creating a plurality of software objects based on the pUoaUty of software classes; and 
constrocting an optimiandon program which uses the plurality of software objects* wherein said 
constructing is performed in response to user input, 
10 wherein the optimization program is useable in controlling the process. 

2. The method of claim 1, wherein the plurality of software classes include at least one of a 
modeling class, a simulation class, and an opdmization class. 

. IS 3. The method of claim 1, wherein' die plurality of software classes include at least two of a 

modeling class, a simulation class, apd an cytimizatinn class. 

4. The method of claim 3, wherein the phiraiity of software classes further include two or more of: 
a visualization class, a deployment class, an execution class, a configuration class, a cormnunication class, a 

20 reporting class, a management class, an archiving class, a pre-processing class, and a post-processing class. 

5. The method of claim l,\^ierein the plurality of software classes include a modeling class and an 
optimization class; 

wherein said creating the plurality of software objects comprises creating a modeling object and an 
25 optimization object 

wherein said constructing die optimization program comprises 'Constructing die optimization program 
usixig die modeling object and the optimizatiGn object 

6. Hie method of claim 1, wherein the plurality of software objects are instances of two or more of 
30 the plurality of software classes; 

wherein the plurality of software objects comprise primitives that are useable in creating higher level 
programs. 

7. The method of claim 1, totfaer comprising: 

3S executing die optimization program, wherein said executing coniprises executing the plurality of software 

objects. 

8. The method of claim 7, wherein said executing the optimizadon program further conq>rises: 
the phirali^ of software objects communicating with each other using event triggered execution. 
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9. The meftod of claim 1, 

wherein said creating the optimization program comprises creating a decision engine, wherein the decision 
engine comprises an encapsulation of knowledge and decision making logic; 

wherein the decision engine comprises two or more of a modeling object, a simulation object and an 
5 optimization object; 

wherein the decision engine conqprises a modular and portable coniponent 

10. The method of claim 1, wherein the one or more management fecilities comprise one or more of: 
a global naming fadUty, a storage arKl retrieval facility, a cataloging and location facility, a project grouping 

10 iacihty, a deployment facility, a revision tracking &cility, and a visualization management &cility. 

11. The mediod of claim I , wherein the optimization program is operable to perform optimization for 
two or more of: continuous processes, batch processes and discrete processes. 

15 12. The method of claim 1, wherein the optimization program is operable to perform control 

functions for two or more of: continuous processes, batch |HOoesses and discrete processes. 

13. Tlie method of claim 1, 

wherein said creating a plurality of software objects includes creating a model software object that 
20 coiiibines a first-priixciples niodel and an ernpiricai riu>deL 

14: The method of claim 1, 

wherein said creating a plurality of software objects includes creating a model software object that 
coiribines two or more of: a first-princq>les model, an eropirical model, and a procedural model. 

25 

15. Hie method of claim 1 , wherein said cieating a plurality of software objects comprises: 
creating a dynamic process model object 

creating a solver olrject; 

wherein the optimization program is constructed includioig tibe dynamic process model object and the 
30 solver object, wherein the dynamic process model object and die solver object operate together to optimize the 
process. 

1 6. Hie method of claim 1 S, wherein said creating a plurality of software objects further conq>rises: 
creating a problem formulation object Hhat describes a problem; 

35 wherein the optimization program is canstnicted including die problem formulation object; 

whcfein the solver object uses information from die.problem formulation object in optimizing die process. 

17. The mediod of claim 15, 
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wherein tfie dynamic process model object comprises one of a first principles model, a linear model, a 

non-linear model, or a hybrid model; 

u^erein the solver object comprises one of a nonlinear programming solver, a mixed integer nonlinear 

programming solver, or an evolutionary solver. 



18. The method of claim 1 5, wherein said creating a plurality of software objects lurtfaer comprises: 
creating a pie-processing object 

wherein tibe optimization program is constructed tnchidiog die pre-processing object; 
wherein the pre-processing object is operable to pre-process data prior to provision of the data to the 
10 dynamic process model object or the solver object 

1 9. . The method of claim 1 5, wherein said creating a plurality of software objects further comprises: 
creating a post-processing object 

wherein ihR optimization program is constructed including die post-processing object; 
15 wherein the post-processing object is operable lo post-process data received ftom one or more of the 

dynamic process model object or the solver object. 

20. The method of claimi 15, 

wherein the dynamic process model object and the solver object comprise a first solution diat controls a 
20 first process; 

the me&od Anther comprising: 

creating a model of the first solution; 

creating a second solution, wherein the second solution comprises a second dynamic process 
model object, a second solver object, and the model of die first solution, wherein the second solution which 
25 operates to control a second process, wherein the second solution affects the first solution; 

wherein die second solution uses die model of the first solution to dynamically determine how the IBxst 
solution will respond to actions provided by the second solution. 

21. ' The method of claim 20, further conqsrising: 

30 the second solution using the model of the first solution to dynamically determine how the first solution 

will respond to actions provided by die second solution; and 

the second solution controlling die first solution based on a determination of how the first solution will 
respond to actions provided by the second solution. 

35 22. Themelfaodof claim 15, further comprismg: 

creating a user interface con^nent for die optimization program; and 
associating die user interface component widi die optimization program. 



24 



wo 01/77872 

23. The method of claim 1, i^erem the process comprises one of: 
opecatio2i, or an e-commeice system. 
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an enteipiise, a manufacturiiig 



24. A control system for oontroUmg a process^ wherein the control system conq>rises: 

S a compiiter system including a processor and a memory mednmij wherein fhs conq^uler system is operable 

to couple to tiie process; 

a phiiality of software classes for modeling, optiiiiizati<m» and deployment; 

one or more numagement facilities for wianagiwg ihe plurality of software classes; 

a plurality of software objects created in response to the plurality of software classes, wherein the plurality 
10 of software objects inherit fimctionality from one or more of the plurahty of software classes; and 
a control program created using the plurality of software objects; 
wherein the control program is useable in controlling the process. 

25. The control system.of claim 24, wherein the plurality of software classes inchide at least two of a 
15 modeling class, a sinmlation class, and an optnnization class. 

26. The control system of claim 24, \^erein the phnality of software classes further include two or 
more of: a visualization class, a deployment class, an execution class, a configuration class, a communication class, 
a reporting class, a management class, an archiving class, a pre-processing class, and a post-processing class. 

20 

27^ Tlie control system ofclaim 24, wherein the plmaUty of software classes include a modd^ 
ami an optimization class; 

wherein the plurality of software objects comprise a modeling object and an optimization object; 
wherein the control program comprises the modeling object and the optimization object 

25 

28. The control system of claim 24, wherein, during execution of the control program, die plurality of 
software objects communicate with each other using event triggered execution. 

29. The control system of claim 24, 

30 wherein the control program comprises a decision engjuie, wherein the decision engine comprises an 

encapsulation of knowledge and decision making logic; 

wherein the decision engine comprises two or more of a modeling object, a simulation object and an 
optimization object; 

wherein the decision engine con^nises a modular and portable component. 

35 

30. The control system of claim 24, wherein the control program is operable to perfoma control 
functions for two or more of: continuous processes, batch processes and discrete processes. 
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3 1 . The control system of claim 24, wherein the plurality of software objects conopnses: . 
a dynamic piocess model object; and 

a solver object; 

wherein (be optimization program comprises the dynamic process model object and the solver object, 
5 wherein the dynamic process model object and die solver object operate together to optimize the process. 

32. The control system of claim 31, wherein the plurality of software olqects further conqirises a 
problem foimulation object diat describes a problem; 

wherein the optcmization program comprises the problem fomiulation abject; 
10 wherein die' solver object uses infom:iation from the problem fomiulation object in optimizing the process. 

33. . The control system of claim 31, 

wherein the dynamic process model object comprises one of a first principles model, a linear model, a 
non-linear model, or a hybrid model; 
IS wherein the solver object con^mses one of a nonlinear programming solver, a mixed integer nonlinear 

programming solver, or an evohiticmary solver. 

34. The control system of claim 3 1 , wherein the phuaUty of software objects further comprises a pre- 
processing object; 

20 herein the optimization program comprises die pre-processing object; 

^^lezein the pre-pzocessio^ object is operable to pre-process data prior to provision of the data to the 
dynamic process model object or die solver object 

35. The control system of claim 31, wherein the plurality of software objects further comprises a 
25 post-pmcessing object; 

wherein die optimization program conq)rises the post-processing object; 

wherein the post-processing object is operable to post-process data received from one or more of die 
dynamic process model object or die solver object 

30 36. The control system of claim 31, 

wherein the (^namic process model object and the solver object con^rise a first solution that controls a 
first process; 

wherein the control system furdier canonises: 
a model of the first solution; 

35 a second solution, wherein die second solution conqxrises a second dynamic process model 

object a second solver object; and die model of the first solution, wherein die second solution operates to ^control a 
second process, wherein the second solution affects the first solution; and 

wherein the second solution uses die model of the first solution to dynamically deteiminB how the first 
solution will re^iond to actions provided by the second solution. 
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37. The control system of claim 3iS, 

wherein the second solution is operable to use the model of the first sohition to dynamically detenoiiie 
how the first solution will respond to actions provided by the second solution; and 

wherein the second solution controls the first sohition based on a detennination of how the first solution 
5 will respond to actions provided by the second sohition. 

3S. The control system of claim 31, fimlier comprising: 
a user interface conoponent for the control program; 

wtmia die user inter&ce conaponent is operable to be associated witii the control program. 

10 

39. The control system of claim 24, wherein die process comprises one of. an enterprise, a 
manufacturing operation, or an e-commerce system. 

40. The control system of claim 24, wherein die control system comprises a plurality of computer 
15 systems interconnected via a network. 

41. A memory medium comprising program instructions for enabling a user to create a program for 
optimizing a process, wherein the memory medium is comprised in a computer system which is coupled to the 
process, wherein the memory medium stores: 

20 a plurality of software classes for modeling, optimization, and deployment; 

one or more management &cilities for managing the phirality of software classes; and 

whmin a phirality of software objects are operable to be created based on the plurality of software 



wherein an optimization program is operable to be constmcted which uses the plurality of software 

25 objects. 

42. Themenaorymediumofclaim41, wherein die niernory medium ftntfaer stores: 

a phiratity of software objects that axe created based on die plurality of software classes; and 
an optimization program that is constructed using the plurality of software objects. 

30 

43. A method for enabling a user to create a program for controlling a process, wherein the method 
operates in a system including a computer system which is coupled to the process, the method comprising: 

providing a plurality of software classes for modeling, optimization, and deployment; 
providing one or more management facilities for managing the phindity of software classes; and 
35 creating a plurality of software objects based on die plurality of software classes, Mierem said creating a 

plurality of software objects conoprises: 

creating a dynamic process model object; and 
creating a solver object; and 



27 



10 



wo 01/77872 PCT/US01/n214 

constiucting an opdmization program which uses die phuality of software objects, wherein said 
constructing is performed in response to user input, -wherein tiie optimization program isxoostmcted including the 
dynamic process model object and the solver object, wherein the dynamic process model object and the solver 
object operate together to optimize the process. 

44. Tlie mettiod of claim 43» wherein said oeathig a phuality of software objects furdier comprises: 
creating a pxoblem formulation object that describes a problem; 

wherein the optimization program is constructed including the problem formulation object 

wherein the solver object uses information from the problem formulation object in optimizing die process. 



45. The me&od of claim 43, 

wherein the dynamic process model object comprises one of a &st principles model, a linear model, a 
non-lmear model, or a hybrid model; 

wherein the solver object comprises one of a nonlmear prograixmiing solver, a mixed integer nonlinear 
IS programming solver, or an evolutionary solver. 

46. The method of claim 43, wherein said creating a plurality of software objects further conqnises: 
creating a pre-processing object; 

wherein the optimization program is constructed including the pre-processing object; 
20 wherein the pre-processing object is operable to pre-process data prior to provision of the data to the 

dynamic process model object or the solver object 

47. The method of claim 43, wherein said creating a plurality of software objects further comprises: 
creating a post-processing object, 

25 wherein the optiiiuzation program is constructed including the post-processing object; 

^nein the post-processing object is operable to post-process data received from one or more of the 
dynamic process model object or the solver object 

48. The method of claim 43, 

30 wherein the dynamic process model object and the solver object comprise a first solution that controls a 



die method further comprising: 

creating a second solution, wherein the second solution comprises a second dynamic process 
model object and a second solver object which operate together to control a second process, wherein the ftst 
35 sohitionafifects the second sohition; 

creating a model of die second solution; 

including the model of the second solution into the^first solution; 
wherein the first solution uses the model of the second solution to determine how the second solution will 
respond to actions provided by die first solution. 
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49. Themethodof claim 43, further conxpiising: 

the first sohidoa using die model of the second solution to dynamically determine how die second solution 
will respond to actions provided by the first solution; and 

die first solution controlling die second solution based on a determination of how the second solutioa will 
respond lo actions provided by die first sohidon. 

50. The method of claim 43, fiirdier comprising: 

creating a user interface component for the optimization program; and 
associating die user interface coirqionent with the optimization program. 

51. The mediod of claim 43, wherein the process comprises one of: an enterprise, a manufacturing ' 
operation, or an e-commerce system. 

52. A mediod for modeling a process, wherein die method operates in a system mcluding a conq>uler 
system, the mediod comprising: 

. creating a sofhvare program that implements a model, wherein the model combines aspects of a first- 
principles model and an empirical model; 

executing the software program to naodel the process. 

53. Tlie method of claim 52, wherein said executing comprises executing a^>ects of the first- 
principles model and die empirical modeL 

54. The mediod of claim 52, further comprising: 

training die model, wherein said training uses empirical data and first-principles information. 

55. The mediod of daim 52, further conqnisiog: 

identifying parametexs of die fiist-principles model based on empirical data, wherein said identiiyii^ uses, 
nonlinear empirical modeling t»:bniques. 

56. The mediod of claim 52, 

wherein die model combines aspects of a first-principles model, an empirical 'model, and a procedural 

modeL 

57. A method foi optimizing a process, die mediod con^rising: 

receiving vsex iapot vAsich configures constraints and targets of the process as a trajectory; 
controlling the process based on die configured constraints and targets of the process^ wherein die process 
is controlled to substantial^ conform to die trajectory. 
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58. The method of claim 57, 

wherein said controUiog die process comprises optimizing &e process according to the configured 
constraints and targets of the process, wherein the process is optimized according to the trajectory. 

59. A mediod for enabling a user to create a program for controlling a process, ^torein the method 
operates in a system including a computer system which is coupled to die process, the method comprisiikg: 

oeating a first solution conoptising a first dynamic process model and a first solver, wherm die first 
solution controls a first process; 

creating a model of the first solution; 

creating a second solution, wherein the second solution comprises a second dynamic process model, a 
second solver, and the model of die first solution, wherein the second solution controls a second process, wherein 
the second solution affects the first solution; 

wherein die second sohition uses the model of the first solution to dstennine how the first solution will 
respond to actions provided by the second solution. 

60. . The method of claim 59, further comprising: 

the second solution using the model of die first solution to dynamically determine how the first solution 
will respond to actions provided by the second solution; and 

the second solution controlling die first solution based on a determination of how the first solution will 
re^ond to actions provided by the second sohitiorL 

61 . A method for enabling a user to create a program for controlling a process,- wherein the method 
operates in a system including a computer system which is coupled to the process, the mediod comprising: 

creating a first solution c omprising a first dynamic process model and a first solver, wherein the first 
25 solution controls a first proc^; 

creating a second sohition, wherein the second solution cornprises a second dynamic process model and a 
second solver, wherein the second solution controls a second process, wherein die first sohition affects die second 
solution; 

creating a model of die second solution; 
30 including the model of the second solution into die first solution; 

wherein the first solution uses the model of the second solution to dynamically determine how the second 
solution will respond to actions provided by the first sohitioiL 

62. Tbe method of claim 61, fiirdier comqirising: 

35 the first sohiticm using the model of die second solution to dynamically detennine how the second sohition 

will le^nd to actions provided by the first solution; and 

die first sohiticm controlling die second solution based on a determination of how die second solution will 
respond to actions jrovided by the first solution. 
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Non-hierarchy decision-making network 
Figure 15 



SUBSTITUTE^HKT (RULE 26) 



wo 01/77872 



PCTAJSOI/11214 



1&29 




CO 










o 

c 


a> 

CD 




b 





CM 

o a> 



<D A 

CO c 
C7> 



0) 









o 


s 


o 


CO 




CD 


IB 


o> 




b 


X 



CO 3 

8> 

Q 1^ 







s 




to 


i 


a> 








b 


X 



SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCT/USOl/11214 



i7/29 



c 
o 

CO 



c 
o 



o 
CO 

© 

'x 

(D 




c 

i 

3 (D 



§ 



8 0) 

— ® 
E 

1 Q £ « 



ID 

o 
p 



It 



5* 

o 

o 2» ^ 
« ,9 o t> 



1 1 • 

.s 1 ^ 

€ £ S « 

a> CO GQ 

o • • • 



5.1 

2 I 

CO o 

m o 



Z UJ 



o 

CO 



SUBSTITUTE^HEET (RULE 26) 




SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCTAJSOl/11214 



19/29 



c 
'55 



u 
o 



•S 
1 

I 



O 6. 
CO 5 

"S "S 
O 

"S 

"O 
XI 
<D 

E 

UJ 



I 

Q 

I 

o 



CD » 

$8 



Q> 
O 

f 




tl 



I 

I 




> 

o 

S' 



i 
I* 



■■ g ? 

O '-5 P 

o E C 

£ o c 

S g s 

fij Is O CD 

o CD .5 c 

■g e g sg « 

■a £ « o £ 

o o o c -c 

XI Z U. Q. UJ 

^ • • • • 



SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCT/USOl/11214 




SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCT/USOi/11214 



2im 




SUBSTITUTE SKEET^RULE 26) 




SUBSTITUTE SHEET (RULE ^) 



wo 01/77872 



PCT/USOl/11214 




SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCT/USOl/11214 




SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCTAJSOl/11214 



25/29 




SUBSTITUTE^HEET (RULE 26) 



wo 01/77872 



PCTAUSOl/11214 




SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCT/US01/11214 



2H29 




(apejo) xapuf )|a|iu 
SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCTAJSOl/11214 



28/29 




( peJ9)xapuni w 
SUBSTITUTE SHEET (RULE 26) 



wo 01/77872 



PCTAISOl/11214 



29f29 




( pej9)x puiti v\i 



SUBSTITUTE SHEET (RULE 26) 



